This invention relates generally to Programmable Logic Devices (PLDs), and more particularly to a method and system for generation and evaluation of architectures for such devices.
Programmable Logic Devices (PLDs) are a widely used form of integrated circuit due to the flexibility provided by their customizable nature. In general PLDs include field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), simple programmable logic devices and laser programmable devices. Architecturally, a PLD includes logic blocks and input/output (I/O) blocks which are connectable through a programmable interconnect structure.
A typical PLD is an integrated circuit chip that, wholly or in part, consists of an array of one or more logic blocks, I/O blocks, and a programmable routing or interconnect network. The interconnect network can be programmed by a user to provide a connection between the logic and I/O blocks to achieve a desired logic function. A PLD can be a standalone device or be embedded in a larger integrated circuit such as ASICs or the like. Exemplary forms of such embedded PLDs are disclosed in U.S. Pat. No. 5,825,202 and U.S. Pat. No. 5,687,325.
The logic blocks may be comprised of a fixed logic function or may in turn also have programmable interconnect networks and programmable functionality. The logic blocks may be firer broken down into sub-blocks or grouped together as a cluster of logic blocks. These blocks may also include I/O circuits that enable connection to external circuits or to other parts of the chip as in the case of an embedded PLD. The I/O blocks are typically arranged at the periphery of a chip.
A PLD is typically arranged as a regular array of logic blocks, each of which may be identical or may be one of several different types (such as memory blocks, look-up table based blocks, p-term based blocks etc.). The conductors of the programmable interconnect network are typically arranged along rows and columns defied by the array of logic blocks, as shown schematically in FIG. 1.
The architecture of a PLD specifies the structure of its logic blocks, I/O blocks and programmable interconnect network. In order to develop a high-quality PLD architecture, the PLD designer must evaluate the impact and utility of a wide range of architectural decisions and trade-offs. The performance of a PLD is typically judged on the basis of operational parameters of circuits implemented in the PLD. These operational parameters include speed of circuits implemented in the PLD, semiconductor or silicon area required to implement a given circuit in the PLD, power dissipation of the PLD after it has been programmed, reliability and routing flexibility.
The typical procedure for evaluating different architectures is shown in FIG. 2. A set of benchmark circuits is implemented in each PLD architecture (or architecture variant) of interest, and the operational parameters of the circuits are analyzed. Generally, PLD designers wish to experiment with as wide a variety of PLD architectures as possible in order to determine the architecture or class of architectures that best meets the operational parameters of interest.
However, in order to implement circuits in a PLD architecture of interest, the PLD designer requires a method of describing the PLD architecture to the CAD tool set. There are two basic components of a PLD architecture: the routing architecture which describes the routing resources or the programmable interconnect network; and the logic (or function) block architecture. Consider first the problem of describing the PLD routing architecture.
To specify a PLD architecture in its entirety, one must specify where every switch, routing wire and logic and IO block pin is located One must also specify which routing wires and logic and I/O blocks can be interconnected by programmable switches, and the delay of every programmable switch, routing wire and circuit path through a logic block in the entire PLD. This is an enormous amount of dataxe2x80x94typically tens to hundreds of MB in size. Accordingly, it is not practical for a PLD architect to specify this data directly for every PLD architecture in which he or she is interested.
The most straightforward way of describing a PLD routing architecture is to create a directed graph (also called a routing-resource graph) that fully specifies all the connections that may be made in the routing of a circuit in the PLD. In essence, this requires the PLD designer to describe where every switch, interconnect wire, logic and I/O block connection pin is located. This description must specify which routing wires, logic blocks and I/O blocks can be interconnected by programmable switches. The description must also specify the delay of every programmable switch, interconnect wire and circuit path through a logic block, in the entire PLD. This is a very general representation of a PLD and is typically the data structure used internally by the routing tool. However, it is not very practical to specify this routing-resource graph manually because the routing-resource graph for a typical PLD requires an enormous amount of dataxe2x80x94typically in the tens to hundreds of megabytes of memory in size. Essentially, this is too low-level a description for a PLD architect to use conveniently.
A more practical approach is to design a basic tile (consisting of a single logic block and its associated routing) manually, and create a program to automatically replicate and stitch together this tile into a routing-resource graph describing the entire PLD routing architecture. However, even the manual creation of a basic tile can be too time-consuming for most PLD architectures. A typical tile contains several hundred programmable switches and wires, so it can take hours or days to describe a single tile. Furthermore, the hand-crafted tile is severely limited in the PLD interconnect or logic block resources that may be variedxe2x80x94for example, a hand-crafted tile is generally designed for one value of the routing channel width, W (the number of routing tracks in a channel). In many architecture experiments, one must vary W in order to see how routable a given PLD architecture is, or to determine the minimum value of W that allows some desired faction of application circuits (say 95%) to route successfully. With a tile based approach, the PLD designer must hand-craft different tiles for each different value of W required to be tested. A PLD designer will often wish to investigate hundreds of different PLD architectures and tens of W values for each of these architectures. The net result is that the PLD designer is required to create thousands or tens of tho of different basic tiles.
There has been some prior work in describing PLD routing at a higher level of abstraction. In [1], Brown et al developed an FPGA router for use with island-style FPGAs. In order to quickly investigate FPGAs with different numbers of routing switches, they localized all the code that interacted with switch patterns to two routines, Fc() and Fs(). By rewriting these two routines, the FPGA designer can target their router (called CGE) to an FPGA with different switch pattern. The later SEGA router [2], used the same method to allow re-targetting to different FPGAs.
In the Emerald CAD system [3], an FPGA""s routing is described by means of WireC schematicsxe2x80x94essentially schematics annotated with C-language like code that describes switch patters. The Emerald system can convert these WireC schematics into routing-resource graphs for use by its FPGA router.
While CGE, SEGA and Emerald all reduce the labour required to specify a PLD architecture, they still require considerable hand-crafting effort. Instead of specifying every switch in a basic tile of an FPGA, these systems allow PLD designers to write software code (in either C or WireC) to generate all the switches in a basic tile. If the PLD designer writes sufficiently general code, it may be possible to change some interconnect and logic resources, such as the channel width W, and have the basic tile adapt properly. However, it is the user""s task to specify this in often non-obvious code.
The second portion of a PLD architecture description details each type of function block (logic or I/O block) contained in the PLD. Both the interface to the PLD routing of each function block (i.e. a list of the inputs and outputs of the block) and a description of the logic functions that can be implemented by the function block, must be provided. A concise method for providing this information is crucial to allow easy experimentation.
As well, timing and area model information for both the routing and function blocks may be included in the PLD architecture description, to allow the CAD tools to estimate the speed achieved by the circuits in this architecture, and the layout area consumed by the architecture.
Accordingly, there is a need for a method and system that reduces the labour involved in describing a complete PLD architecture and allows the easy variation of many interconnect and logic resource parameters of the architecture.
In accordance with this invention there is provided a system for generating a PLD architecture comprising:
an Architecture Generation Engine for converting a high-level, easily specified description of a PLD architecture into the highly detailed, complete PLD architecture database; the detailed PLD architecture used by the CAD toolset to map a circuit netlist into the PLD.
In a further embodiment, the Architecture Generation Engine also enables the performance evaluation of a wide variety of PLD architectures for given benchmark circuits.
In a further embodiment of the invention, there is provided a CAD system for implementing circuits into PLD architectures and for evaluating performances of different architectures.
In accordance with a further embodiment of the invention, there is provided a method for generating an architecture for a programmable logic device (PLD), the method comprising the steps of:
creating a data file defining a high-level architecture description of the programmable logic device;
creating unique functional elements of the PLD generally matching the description in the data file;
replicating and stitching together the functional elements to create a complete PLD architecture; and
generating a detailed description from the complete PLD architecture, for use by a CAD toolset